Some people would be happy to convince you that managing an Open Source Software (OSS) project is completely different than managing acommercial software project. People working on Open Source software argue thatthere are no deadlines to meet, that quality issues can be left for thecommunity of users to identify, and that their are no complications of costingand budgeting to manage. I will hopefully have convinced you of the contrary bythe end of this article. I will have showed you that managing a normal softwareproject and an open source project has far more parallels than most people would have you believe.
Do the common project life cycle principals apply to the average Open Source Software project? Do OSS projects go through the phases ofdefinition, planning, organising, execution and closure? It is perhaps not quiteas formal, but if you look hard enough the same phases of the developmentprocess can be found in all OSS projects. Whether it's conscious orsubconscious, OSS projects all follow the common development stages. In fact itcan probably be argued that the successful OSS projects follow these principlesintuitively and instinctively. Good project management practices really can make the difference between successful and unsuccessful OSS projects.
Take for example the appointment of a project manager. The majority of OSS projects don't formally appoint an official project manger, yetin most projects you will find someone taking on the role of project manager. Heunderstands the significance of the development process and the importance of leading a good team.
So what is it that an unofficial OSS project manager might bring to the successful OSS project? As mentioned earlier, the project managercan't ignore the familiar stages making up the common software development process:
- Project Definition
- Planning
- Organising
- Executing
- Closing
However, following this development process amounts to very little if the project manager has little understanding of the key leadershipskills involved. The ability to specify precise goals, to communicate clearlyand to motivate members of the project is crucial to the leadership. In the OpenSource environment, the motivation of the team members presents the realchallenge. The familiar financial motivation plays no part in many open sourceprojects. For most developers working in an OSS environment, you will probablyfind the following motivators having the biggest impact on the project:
- Achievement
- Recognition
- Responsibility
- Advancement
None of these motivators are tangible, but you have to pay close attention to them in OSS projects. It is easy in commercial projects toover look these points and focus on the more tangible motivator known as money.If you want a truly motivated team though, concentrate on both the tangible and the intangible motivators!
Even in the apparently chaotic world of open source software development, clear process and good leadership are essential tenets. The processmay be more fluid in an OSS project and the leadership less formally defined,but both aspects are just as important all the same. In the following sectionswe will look at the stages of the project development process in the OSS context and see how team motivation plays its part in each of these stages.
Project Definition
"Project Definition" sounds very formal, but its importance can't be too highly stressed. The problem definition influences everything within your project. Whilst working on an OSS project we may not formally document that we need achieve X and Y, but in many cases the objectives of an OSS project are far clearer in the minds of the OSS project team than that of the commercial software development team.
In the case of a commercial software development team, you might typically have someone define what needs to be achieved and then communicate that vision to the development team, hoping that they understand it. In the OSS scenario, you typically have a group of developers that have come together because they have all experienced, first hand, the "problem definition". This makes it is far easier to understand the problem and see a route to the solution.
Defining the 'problem' and specifying the requirements isn't always straightforward. However, this is where most OSS projects have an advantage over their commercial counterparts. By far the best way to understand a requirement is not to read it, but to experience it. Most OSS developers have experienced the need to fulfil a particular requirement. After all, coming up against the problem is probably the main reason they've picked a particular OSS project to work on in the first place. Experiencing the need for a requirement first hand will always provide a better understanding than reading a written requirement specification second hand.
With a clear definition of the problem you are already ahead when it comes to motivating the team. Having a clear goal is absolutely key to engendering a feeling of achievement as the project evolves. You can only feel like you've achieved something, or that you are progressing, if you know what you are aiming for. So make sure you define the project and that you communicate that definition clearly to the rest of the team.
Planning
When you think of Open Source projects, formal project planning isn't one of the first tasks that spring to mind. Open Source projects have a reputation for a slightly more ad-hoc approach to planning. Maybe the OSS approach to planning isn't formal but, believe it or not, it is still a step that needs to be taken seriously. The OSS projects that succeed may not have formally defined project plans, but you can guarantee that the team has an instinctive ability to plan and organise their work.
The almost religious reliance on defect tracking tools (e.g. Bugzilla or Mantis) is possibly one of the reasons OSS teams are so good at identifying and organising tasks. In the OSS environment, the teams defect-tracking tool turns into far more than just a tool for tracking defects. It becomes the foundation that helps to organise and priorities the work of the whole team. It tracks everything from release tasks, defects, enhancement suggestions and, sometimes, even the to-do lists of individual developers. The defect tracking system's effectiveness at prioritising and assigning tasks comes into its own within many OSS projects. Without the pressures of deadlines, the complexity of tools like Microsoft Project can be left behind for defect tracking tools that are far easier to implement and run.
The use of system architecture and design definition is possibly the weakest link in this comparison with formal project management.Whilst in commercial projects it is common to see reams of paper specifying thedesign of the system, it is not common to see this sort of work on an OSSproject. In a typical OSS project, it is common for design ideas and concepts tobe quickly prototyped in code and distributed to the community for feedback andcomment. Even if it is perhaps not the most efficient use of time and resources,this proves to be an effective mechanism for identifying what should and shouldnot be included in the application. Personally I advocate a least a certaindegree of formal design work before coding begins. Formal design specificationsadd clarity to the project and help foster a feeling of advancement as the project progresses.
It is during the planning phase that serious consideration needs to be given to matching the goals of the project with the goals of theteam members. One of the key reasons people get involved in OSS projects is toimprove their skills and experience. If you decided to implement your projectusing Pascal, you would likely limit the pool of potential developers to work onthe project, or even empty it. If, however, you select one of the more popularand exciting technologies, you are more likely to attract and retain coders onyour project. Again the feeling of advancement whilst building and developing new skills helps to create an environment of motivation.
